Release 10.1A: OpenEdge Application Server:
Developing WebSpeed Applications

set-transaction-state

This procedure changes the current database transaction state for the WebSpeed agent. The database transaction state can have the following values:

NONE — The agent is not in a database transaction.
START-PENDING — The agent is currently not in a database transaction, but will start the next request cycle in a database transaction (after the current request completes).
ACTIVE — The agent is currently in a database transaction.
UNDO-PENDING — The agent is in a database transaction that will be undone before the next request cycle (after the current request completes).
COMMIT-PENDING — The agent is in a database transaction that will be committed before the next request cycle (after the current request completes).
RETRY-PENDING — The agent is in a database transaction that will be undone before the next request cycle, when a new transaction will be started. (This is equivalent to UNDO and START before the next request cycle.)
Location: web\objects\web-util.p
Parameters:

INPUT pState AS CHARACTER

The database transaction state to set. Only four of the six database transaction states can be set programatically: START-PENDING, UNDO-PENDING, RETRY-PENDING, and COMMIT-PENDING.

Notes:

You can omit -PENDING when typing state values in your code. For example, START is equivalent to START-PENDING.
You can only set the transaction state to START-PENDING if the current state value is NONE. You can only set the transaction state to UNDO-PENDING’, RETRY-PENDING, and COMMIT-PENDING if the current state value is ACTIVE. Trying to set the transaction state in any other case results in an error.
If you attempt to start a transaction, and there are no state-aware Web objects created or in existence at the end of the Web request, then the transaction state reverts to NONE for the next request.
States of ACTIVE, UNDO-PENDING, RETRY-PENDING and COMMIT-PENDING all indicate that a database transaction is active.
When you set the transaction state, the new state does not take affect until the start of the next request cycle. It is therefore good practice to set the value near the bottom of your process-web-request, where you are certain no changes to variables or tables will occur in the current request that you might want undone in a subsequent request.
If the transaction state is UNDO-PENDING or RETRY-PENDING, do not set any undo-able variables or tables, unless their values after the current request completes is unimportant. All changes to these variables and tables are lost at the end of the current Web request, when the current database transaction is undone. Similarly, if you look at the value of these variables and fields during the next request, they will show the old values for the duration of the Web request.
Examples:

\* Get the submitAction field (set on SUBMIT buttons) and reset the transaction-state. Note that on a COMMIT or UNDO, we want to return to the menu page. The current page will be returned only in the RETRY case. *\ DEFINE VARIABLE c_action AS CHARACTER NO-UNDO. c_action = get-field('submitAction':U). CASE c_action: WHEN 'UNDO':U OR WHEN 'COMMIT':U THEN DO: RUN set-transaction-state IN web-utilities-hdl (c_action). RUN run-web-object IN web-utilities-hdl ('main.w':U). RETURN. END. WHEN 'RETRY':U THEN DO: RUN set-transaction-state IN web-utilities-hdl (c_action). \* Output the MIME header. *\ RUN outputHeader. END. END CASE.

See also:

get-transaction-state